related to issue

What was done

• Branches: master (no bulk load) vs bulk_loading (BTree BulkPutSorted in flusher + compactor).
• Tool: wildcatdb/bench, fillseq only.
• Configs:
  • A – many small flushes: write_buffer_size=262144, num=100000
  • B – medium flushes: write_buffer_size=2097152, num=100000
  • C – few large flushes: write_buffer_size=8388608, num=200000
• Runs: master = 2 runs per config; bulk_loading = 1 run per config.

Results

Summary

• End-to-end fillseq does not show a clear, consistent win for bulk_loading.
• SSTable counts differ a lot between branches (e.g. config A: master 3–4 vs bulk_loading 22), so we’re not comparing the same flush/compaction behavior. That makes it hard to attribute throughput differences to bulk load alone.
• Config B: bulk_loading was faster in the single run; config C: bulk_loading was slower with more SSTables. High variance on master (B and C) suggests more runs would help.

Ask for help

1. Why might bulk_loading produce more SSTables (e.g. 22 vs 3–4 on config A)? Is there a known difference in when flushes are triggered or how compactions run on the bulk_loading branch that could explain this?
2. Best way to measure bulk load benefit: Would a flush-only micro-benchmark (e.g. fixed N keys, time only the B-tree build during flush on master vs bulk_loading, same N) be the right next step to isolate the effect of bulk insertion without conflating with flush count / compaction?
3. Any guidance on making bulk loading show a measurable benefit in real workloads (e.g. recommended write_buffer_size or workload shape), or on code paths to double-check (e.g. slice building, flush trigger conditions) would be very helpful.

Thanks in advance.